At present, in IETF (Internet Engineering Task Force), efforts are in progress to standardize various types of communication technologies. As one of the communication technologies discussed in this IETF, for example, there exists a multihoming technology in which an MN (Mobile Node) introducing the mobile IPv6 (see the following Non-Patent Document 1) to have a mobility function (mobility management function) makes communications by using a plurality of addresses simultaneously. For example, the following Non-Patent Document 2 describes diverse situations in which an MN comes into a multihomed condition in conjunction with a combination of the number of interfaces, the number of HoAs (home addresses) and the number of CoAs (care-of addresses) in the MN.
In addition, the Non-Patent Document 1 suggests a technique of, when an MN has a plurality of HoAs, inhibiting that a different HoA is used as a CoA. On the other hand, the Non-Patent Document 2 describes that a different HoA is registered as a CoA as an effective case in a multihoming technology and there is a need for an extension of the definitions of an HoA and a CoA and a method of selecting an HoA to be registered as a CoA.
With reference to FIG. 6, a description will be given hereinbelow of, in a conventional multihoming technology, an infinite transfer loop between HAs which can occur in a case in which an MN has a plurality of interfaces and HoAs are allocated from a plurality of HAs (Home Agents) thereto.
FIG. 6 is an illustrative view showing one example of a condition in which an infinite transfer loop is possible with a conventional multihoming technology. FIG. 6 shows an MN (1100) which makes a communication through a network (1300) with a CN (Correspondent Node) (1200).
As shown in FIG. 6, let it be assumed that the MN (1100) has two interfaces and both the two interfaces of the MN (1100) are connected to HNs (Home Networks) to which they pertain. Moreover, let it be assumed that in each of the interfaces there are set HoAs (HoA.h1 and HoA.h2) allocated respectively from an HA1 (1110) and an HA2 (1120).
FIG. 6 is an illustration of a state in which the MN (1100) is connected through links, drawn between the MN (1100) and the HA1 (1110) and between the MN (1100) and the HA2 (1120), to an HN1 (not shown) where the HA1 exists and to an HN2 (not shown) where the HA2 (1120) exists.
In addition, let us assume that the MN (1100) is capable of registering a plurality of CoAs in the HA1 (1110) and the HA2 (1120) and of registering, as CoAs, HoAs under management of other HAs. Accordingly, the MN (1100) can carry out the binding update of the HoA.h2, associated with the HoA.h1, with respect to the HA1 (1110) while it can conduct the binding update of the HoA.h1, associated with the HoA.h2, with respect to the HA2 (1120).
In FIG. 6, a binding cache of each of the HA1 (1110) and the HA2 (1120) is illustratively shown with respect to the MN (1100). The HA1 (1110) can refer to its own binding cache to transfer a packet, addressed to the HoA.h1, to the HoA.h1 or the HoA.h2, and the HA2 (1120) can refer to its own binding cache to transfer a packet, directed to the HoA.h2, to the HoA.h2 or the HoA.h1.
In this connection, in a conventional technique and in an embodiment of the present invention described hereinafter, a binding update method for generating such a binding cache and a binding cache holding method are not particularly limited, but arbitrary methods are employable.
Furthermore, the occurrence of an infinite transfer loop substantially depends upon the fact that a transfer is made on the basis of the registration to a different home network but it has less connection with a method of handling a home address allocated in a home network which is in connection. For this reason, in this specification, although the description of both the conventional technique and the embodiment of the present invention takes up, as an example, a case in which an interface which establishes connection with a home network registers an home address, allocated in the connected home network, in a home agent (for example, in FIG. 6, registering the HoA.h1 existing a CoA entry of a binding cache of the HA1 (1110)), an arbitrary method is employable as a method of registering an address when an interface is connected to a home network. For example, as an address registering method, in addition to the intact registration of a home address, it is possible to employ the acquisition and registration of a care-of address for the connection with a home network, the registration of information indicative of the presence of an interface connected to a home network and a combination thereof. Moreover, it is also acceptable to inhibit a special operation related to the address registration. Incidentally, even in the case of using one of the above-mentioned methods within a range which does not constitute departures from the spirit and scope of the invention disclosed by this specification, it is obvious that the processing procedure according to the present invention disclosed by this specification does not impair the originally intended effects/advantages.
Let it be assumed that the HoA.h1 is set as a destination address of a packet when the CN (1200) carries out the packet transmission to the MN (1100). The packet whose destination is the HoA.h1 transmitted from the CN (1200) can pass through a route indicated by a thick-line arrow in FIG. 6.
That is, the packet whose destination is the HoA.h1 transmitted from the CN (1200) first arrives at the HA1 (1110), and the HA1 (1110) transfers it. At this time, on the basis of some policy or algorithm, the HA1 (1110) refers to its own binding cache to determine transferring the packet to the interface of the MN (1100) in connection with the HN1 or performing the packet encapsulation and then transferring it to the HoA.h2.
In a case in which the packet is transferred to the interface of the MN (1100) connected to the HN1, the MN (1100) can receive the packet at this time. On the other hand, if it is encapsulated and transferred to the HoA.h2, this encapsulated packet arrives at the HA2 (1120).
As well as the HA1 (1110), on the basis of some policy or algorithm, the HA2 (1120) refers to its own binding cache to determine transferring the packet to the interface of the MN (1100) in connection with the HN2 or performing the packet encapsulation and then transferring it to the HoA.h1.
In a case in which the packet is transferred to the interface of the MN (1100) connected to the HN2, the MN (1100) can receive the packet at this time. On the other hand, if it is encapsulated and transferred to the HoA.h1, this encapsulated packet again arrives at the HA1 (1110). Moreover, as a result of the packet transfer processing being again conducted in the HA1 (1110), there is a possibility that the packet is transferred to the HA2, and the packet falls into an infinite transfer loop state in which it is transferred infinitely between the HA1 (1110) and the HA2 (1120), which can make it difficult for the MN (1100) to receive the packet.
Although there is a possibility that the packet is sent to the interface of the MN (1100) according to some policy or algorithm after the transfer thereof is conducted once or repeatedly conducted several times between the HA1 (1110) and the HA2 (1120), also in this case, redundant transfer will occur.
Meanwhile, in the above-mentioned case, in a manner such that an integrated judgment is made on MN binding information contained in a binding cache of each HA forming a passing point of the infinite transfer loop, it is possible to grasp the occurrence of an infinite transfer loop of a packet addressed to the MN. For example, in the example shown in FIG. 6, the infinite transfer loop impossible condition is taken by deleting an HoA registered as a CoA in one of the HA1 (1110) and the HA2 (1120).
Therefore, for example, in a manner such that all the HAs search the occurrence of an infinite transfer loop in cooperation with each other (for example, they confirm the MN binding information contained in the binding caches or append some loop detection identifier to the packet transferred), it is possible to detect the fact that the packet addressed to the MN falls into an infinite transfer loop condition.
In this case, for example, all the HAs are required to introduce functions (each of which will be referred to hereinafter as an abnormal transfer measures function) for preventing an infinite transfer loop condition, such as packaging a function to notify the MN binding information contained in its own binding cache to another HA and a function to append a loop detection identifier and further establishing security association between the HAs.
Moreover, when the MN simply fixes an HoA, to be used, to one of a plurality of HoAs allocated, the infinite transfer loop is preventable in advance.
For example, in the example shown in FIG. 7, the MN (1100), all interfaces of which are connected to the HNs to which they pertain, registers an HoA, managed by each of the HA2 (1120) and an HA3 (1130), as a CoA with respect to only the HA1 (1110), and notifies the HoA under the management of the HA1 to three CNs (CN1 (1210), CN2 (1220) and CN3 (1230)). In this way, as indicated by thick-line arrows in FIG. 7, the packets transmitted from the CN1 (1210), the CN2 (1220) and the CN3 (1230) to the MN (1100) arrives at the HA1 (1110) and then they are sent to the interface of the MN (1100) directly or through another HA, thus suppressing the occurrence of an infinite transfer loop.
Non-Patent Document 1: D. B. Johnson et al., “Mobility Support in IPv6”, RFC3775, June 2004.
Non-Patent Document 2: N. Montavont et al., “Analysis of Multihoming in Mobile IPv6”, draft-montavont-mobileip-multihoming-pb-statement-04.txt, Jun. 8, 2005
However, in a case in which at least one of a plurality of HAs which can serve as passing points of a packet in an infinite transfer loop does not have the above-mentioned abnormal transfer measures function, difficulty is experienced in detecting the infinite transfer loop. Moreover, in a case in which an MN is equipped with a plurality of interfaces and a large number of HoAs, since there is a possibility of the formation of an infinite transfer loop passing through a large number of HAs, even if all the HAs incorporate an abnormal transfer measures function, there is a possibility that an HA(s) disabling the abnormal transfer measures function exists, for example, because of an increase in processing load.
In addition, with a method in which an MN selectively uses only one of a plurality of HoAs, the MN itself becomes capable of preventing an infinite transfer loop in advance. However, this state does not lead to effectively making efficient use of communication routes to a plurality of networks, and results in abandoning a portion of advantages attainable by the multihoming technology. For this reason, this state is not desirable. In particular, the load of the processing on the packet addressed to the MN concentrates on the HA1 (i.e., the HA1 (1110) in FIG. 7) managing the selected HoA and, in this case, other HAs substantially fulfill only a function as an AR (Access Router).
In a case in which an MN simply comes into connection with an HN, by avoiding the registration of a CoA under the management of another HA in an HA within the HN and by properly adjusting its own HoA to be notified to a plurality of CNs, it is possible to realize the distributed reception of packets at a plurality of interfaces while avoiding the occurrence of an infinite transfer loop. However, this method creates a problem in that the flexibility of a communication system disappears. There is a possibility that a destination address (HoA of the MN) to be used by the CN for the packet addressed to the MN is changed and, as a result, for example, the re-establishment of a session between the CN and the MN or the like occurs.